As computer science has evolved, object oriented programming has become one of many familiar models designers and programmers utilize to implement functionality within computer systems. The object model generally is defined by a class structure that includes class members providing both methods and associated data elements belonging to the class. The class members thus provide/define desired functionality within a computer program, wherein an object is declared as an instance of a particular class. As is commonplace, objects often must exchange data and/or invoke other objects operating on the same platform and/or communicate with objects belonging to remote platforms. In order to communicate between objects, interface systems and standards have been developed to define how objects may communicate and/or interact with one another.
A familiar system for communicating and interfacing between objects is known as the Component Object Model (COM), wherein another similar system is referred to as the Common Object Request Brokers Architecture (CORBA). Still yet other communication interfaces may be defined in languages such as JAVA within an operating framework of a Java Virtual Machine, for example. As these and other systems have been developed however, two common object architectures or models generally have emerged and may generally be defined in terms of managed and unmanaged object systems, for example.
Managed objects may be allocated from a heap within a managed software environment and are generally not responsible for managing associated object lifetimes. Managed objects may be described in terms of a data type (e.g., metadata) and automatically collected (e.g., reclaimed) by a managed environment “garbage collector” that removes the object from memory when the object is no longer being accessed. In contrast, unmanaged objects may be allocated from a standard operating system heap, wherein the object itself is responsible for freeing memory it employs when references to the object no longer exist. This may be accomplished through well-known techniques such as reference counting, for example.
Managed applications and/or objects can execute calls to unmanaged Application Program Interfaces (APIs) (e.g., operating system APIs, entry points into dynamically loaded dynamic link libraries (DLLs), entry points into COM components) by a process called “platform invoke.” In general, a call from managed to unmanaged code requires some additional code to be executed as part of a transition between the two execution models. For example, this may entail: potentially marshalling a plurality of arguments and return values (e.g., depending on the actual data-type, some data-types may not have similar representations in managed and unmanaged code); locating multiple markers on an execution stack (e.g., in order that a managed system can locate “managed” and “unmanaged” segments of the execution stack); considering thread execution on return from unmanaged to managed code; and potentially managing security issues between the execution environments.
In a general situation, this can be implemented by directing the call through an external interface referred to as “stub-code” that can perform these operations. Unfortunately, one or more of these stub-code operations are particularly time intensive (e.g., as compared to a regular call of a function in the same object system). For example, by utilizing a call through the stub, stack-based arguments often need to be copied onto a different stack location (i.e., the arguments need to be pushed again)—even if marshalling for the actual data-types is unnecessary. Another problem relates to adding markers on the stack and can involve an explicit update of a linked list, for example, such that access to the root of that list is comparatively expensive (e.g., processor execution cycles). Due to these and other issues relating to communications between object systems, there is a need for a system and methodology to facilitate improved execution performance when invoking functions and/or objects between object systems.